Portable contactless devices, such as, for example, mobile communication devices, such as cellular phones, PDAs (PDA: Personal Data Assistant), or dedicated devices can dispose of a communication interface for wireless short range communication with a target. Such an interface can be used for executing transactions between the mobile device and the target. The transactions may be financial transactions allowing making an electronic payment using the mobile device. Another example is an electronic ticketing transaction, in which an electronic ticket is provided by the mobile device and validated by the target.
The contactless communication interface usually comprises a controller that controls the antenna on the lower levels, particularly on the physical level and possibly on the level of the contactless data exchange protocols. On an application level the execution of transactions is controlled by contactless applications. In case of transactions, such as financial transactions, which involve sensitive data, the contactless applications are executed in a secure element connected to the contactless communication interface. The secure element provides a security architecture preventing unauthorized third parties from accessing the sensitive data.
It has already been proposed to integrate the secure element into a smartcard included in the contactless device, which includes a processor for executing applications, and which is coupled to the contactless interface. In case of a mobile communication device, the smart card may be a user identification card, which may be a SIM (Subscriber Identity Module) card according to the GSM (Global System for Mobile Communications) standard or a UICC (Universal Integrated Circuit Card) comprising a USIM (Universal Subscriber Identity Module) application according to the UMTS (Universal Mobile Telecommunications System), for example. Such smart card provides secure identification and/or authentication services towards a mobile communication network, in which the mobile communication device is used. By utilizing the user identification card for executing contactless transactions, the existing security architecture of the user identification card can be used.
However, the resources of a smart card to store and/or execute applications are usually relatively restricted and there may be contactless applications which require a lower degree of security than the smart card provides. Therefore, it may be advantageous to be able to execute at least selected contactless applications not in the smart card but in another processor of a contactless device in order to conserve resources of the smart card. A further reason for executing a contactless application in another processor of the contactless device may be that such applications may be easier to develop than applications for execution in a smart card, particularly since higher level programming languages may be used.
Contactless applications executed in a further processor outside of the smart card coupled to the contactless interface may use an interface within the device to access the contactless interface. One example of such interface is the Contactless Communication API (Application Programming Interface) described in the document JSR (Java Specification Request) 257.
A first drawback of such interface may be that accesses to the contactless interface via the interface may conflict with accesses by contactless applications executed in the smart card, so that an appropriate conflict management has to be provided. Conflict management may for example involve the user manually selecting whether contactless applications in the smart card or in the processor external to the smart card are allowed access to the contactless communication interface.
Furthermore, the security level of contactless applications executed in the smart card may be reduced, when the smart card loses exclusive access to the communication interface. For instance, a malicious application executed outside the smart card could be presented to the user with a similar look and feel as a secure application executed in the smart card and the user could not be aware of different security levels. The application could, for example, launch a phishing attack and ask the user to input sensitive data, such as, for example, banking details or passwords. Also, a malicious application executed outside the smart card may preempt the communication interface and prevent that contactless applications executed on the smart card gain access to the communication interface.